feat: ignore encryption preferences #6612
Conversation
link2xt
force-pushed
the
link2xt/ignore-encryption-preferences
branch
2 times, most recently
from
7ad7fcc to
c4d8826
Compare
link2xt
force-pushed
the
link2xt/ignore-encryption-preferences
branch
3 times, most recently
from
c8b1f04 to
f2e3f44
Compare
link2xt
changed the base branch from
link2xt/clone-accounts
to
link2xt/account-apis
link2xt
force-pushed
the
link2xt/ignore-encryption-preferences
branch
from
f2e3f44 to
f92606b
Compare
link2xt
force-pushed
the
link2xt/account-apis
branch
from
1e31f3e to
aba9544
Compare
link2xt
force-pushed
the
link2xt/ignore-encryption-preferences
branch
from
723e691 to
40e477e
Compare
link2xt
force-pushed
the
link2xt/account-apis
branch
from
aba9544 to
491d6ab
Compare
link2xt
force-pushed
the
link2xt/ignore-encryption-preferences
branch
4 times, most recently
from
91d5151 to
69c2277
Compare
Encryption preference is sent in Autocrypt header, but otherwise ignored. Delta Chat always prefers encryption if it is available.
link2xt
force-pushed
the
link2xt/ignore-encryption-preferences
branch
from
69c2277 to
859b5b8
Compare
|
We need to think about hermes.radio usecase, it sets the config but the config is not going to have any effect. hermes.radio currently relies on stripping Autocrypt to downgrade everyone to unencrypted. Maybe they don't want to have encryption key at all, or maybe could be fine with encryption if we build high compression mode into the core so the server does not need to recompress. I am not removing the setting completely because we have it set in provider database for hermes.radio, but we are definitely breaking this usecase so need to discuss it separately. |
There was a problem hiding this comment.
Why does this break the hermes.radio usecase? If they strip the Autocrypt headers, then DC can't encrypt, so it won't.
What might break their usecase is the new QR codes that will be encrypted with a symmetric secret and don't leak Autocrypt header, but we can think of this when it's time (I mean, for now they are only a rough idea, nothing concrete).
If this makes problems for them, we can always hardcode non-encryption (e.g. add if self.get_config(Config::E2eeEnabled).await? { return Ok(false); } to the beginning of should_encrypt()).
There was a problem hiding this comment.
FTR, the important semantic change is in this file here, everything else is just tests
Always prefer encryption if it is available.
This is in preparation for PGP-contacts as we want to clearly separate encrypted and unencrypted chats instead of having them switch between encrypted and unencrypted based on majority vote.